תיק )מסמך( אפיון ת ו כ ן ה ע נ י י נ י ם 0. מנהלה 1. יעדים 2. יישום - מהות המערכת 3. טכנולוגיה ותשתית 4. מימוש 5. עלות משאבים נספחים

Transcription

1 מהדורה 10 נוהל מפת"ח ג ל ו פ ת ל י מ ו ד מסמך זה הוא של תיק אפיון, תורתית ומלאה )רמה 3 ולעתים קרובות גם רמה 4 ויותר של עץ המערכת( וכולל את כל רכיבי עץ המערכת בהיבטים של השלב הנוכחי שלב האפיון. הנחיות מפורטות לשימוש בגלופה זו נמצאות במדריך המלא בקיט אפיון מערכת. שימוש בגלופה זו מותנה ברישוי מפת"ח ת ו כ ן ה ע נ י י נ י ם 0. מנהלה 1. יעדים 2. יישום - מהות המערכת 3. טכנולוגיה ותשתית 4. מימוש 5. עלות משאבים נספחים

2 עמוד 2 מתוך מנהלה. 0 מ נ ה ל ה פרק זה משמש לניהול ובקרה של שלב האפיון. גורמים מעורבים, תכנית העבודה, מעקב ביצוע מול תכנון, ניהול תצורה ומעקב שינויים של התיק עצמו, אישורים, אבטחת איכות וכו'. שים לב להבדל בין פרק זה ובין פרק 4 מימוש להלן. פרק זה מיועד לניהול שלב האפיון עצמו, פרק 4 מתאר את תכנית הפיתוח הכוללת של המערכת )מעבר לשלב הנוכחי( ואת אופן תפעול המערכת ותחזוקתה. עם סיום השלב הנוכחי, פרק 0 כבר אינו רלוונטי. פרק 4, לעומת זאת, הוא חלק מרכזי של תוצרי המערכת. )בשלב הבא יתעורר פרק 0 מחדש לתיאור אותו שלב(. בשלב בקשה להצעות הופך פרק זה להיות פרק המנהלה ויש לו מבנה מחייב מיוחד. ראה הקיט בקשה להצעות RFP בכרך יסודות \ מחזור חיים. רמת הפירוט של פרק זה ומבנהו המדויק נתונים לשיקול דעתו של הפרויקט \ הארגון. ביחידות צה"ל יש להקפיד על אישורים לפי הנחיות צה"ל/מקשר"ר/מצו"ב/במ"מ ובפרט אישור אחראי במ"מ. בהקשר עם האישורים, ובהקשר עם המנהלה של שלב האפיון כולו, חשוב לחזור ולהדגיש את תמצית המנהלים. לעיתים קרובות יאשר דרג מסוים את תמצית המנהלים ודרג אחר את תיק האפיון המלא. ראה פרק תמצית מנהלים בקיט תיעוד בכרך נושאים תומכים. תמצית המנהלים הוא מסמך נפרד, מחוץ לתיק זה, ומוצג לפניו. בכל דיון/שיקוף, בפרט בדיונים עם הצוות המנהלי, יש להקפיד על הגשת תמצית מנהלים )מסמך אפיון מקוצר לדרג הניהולי( בצמוד לתיק האפיון המלא. עם זאת, יש להקפיד על כך שהאישור הסופי, ע"י הצוות המנהלי לפרויקט, יהיה על תיק האפיון המלא ולא רק על תמצית המנהלים. 0.0 כללי תיאור מקוצר של השלב הנוכחי בו נמצאת המערכת )ושבמהלכו מופק תיק זה(. גורמים מעורבים הצוות המקצועי )פנימי או חיצוני( המבצע )מיועד לבצע( את אפיון המערכת. צוות ההיגוי המנהלי )לאפיון( תכנית עבודה ראה הצעה בסעיף פעילויות )תכנית עבודה( במדריך המלא. Pert\CPM במקרים מורכבים: תרשים גאנט, ברוב המקרים מספיק: טבלת רשימת פעילויות ראשיות, מועדי סיום, מבצע ראשי וכו'. מעקב ביצוע מול תכנון )על התרשים או בתוך הטבלה( כלים ונהלי עבודה כלים ונהלי עבודה של השלב הנוכחי 0.3

3 עמוד 3 מתוך מנהלה 0.4 ניהול תצורה ומעקב שינויים להלן טבלת מעקב שינויים )ניהול תצורה( של השלב )התיעוד( הנוכחי: תאריך מהדורה \ בסיס מס' רכיב תיאור השינוי מאשר 0.5 אישורים בדרך כלל, החתימות שבעמוד השער ובטבלה שבסעיף הקודם מספיקות. אם בכל זאת יש צורך באישורים ספציפיים, יש להשתמש בטבלה הבאה: הערות חתימה מייצג )מחלקה( שם תאריך

4 עמוד 4 מתוך יעדים. 1 י ע ד י ם 1.0 כללי הבהקים אפשר בשלב ביניים, לכלול בסעיף זה נושאים ודגשים כלליים של יעדי המערכת )עקרונות יסוד, אילוצים, מטרות כלליות וכו'(, אשר במהלך האפיון חשוב לזכור אותם ושמקומם הסופי לא ברור. במהלך בניית התיק יועברו נושאים אלה למקומם הטבעי באחד מהרכיבים בפרק זה )X.1( או בפרקים הבאים. בשום פנים ואופן אין להפוך רכיב זה לאפיון המערכת כולה! לכל מידע המופיע כאן יש מקום טבעי וברור בפרקים וברכיבים דלהלן. בצורתו הסופית, יכיל סעיף זה אך ורק עקרונות יסוד, תפיסה כללית וכו', נושאים אשר חשוב להדגישם, במבנה של הבהקים (Highlights) של יעדי המערכת, לפי הדוגמא להלן. זכור שסעיף זה יופיע בד"כ בתמצית מנהלים שתופק מתיק זה. ראה קיט תיעוד בכרך נושאים תומכים. דוגמא להבהקים: אפיון המערכת מגדיר שתי מהדורות. מהדורה 1 למימוש מיידי ומהדורה 2 למימוש בהמשך. בכל סעיף להלן, יש התייחסות ברורה לשתי המהדורות. במערכת שתי תת-מערכות מרכזיות, תת-מערכת א' ותת-מערכת ב'. ראה חלוקה פונקציונאלית של המערכת בסעיף 2.3 להלן. למרות חלוקה ברורה זו, נחשבת המערכת לאחת )בשלב זה(. למערכת ישנם ממשקים חשובים ביותר עם מערכות חיצוניות, הן ממשקי קלט והן פלט. ראה פירוט ממשקים אלה ברכיבים 2.2 ו להלן. המערכת מושתתת על הגדרה ברורה של ישויות המידע הבאות: חוזה מספר קטלוגי חשבון ספק סופי. ראה הגדרה מדויקת של ישויות מידע אלה ואחרות ברכיבים 2.13 ו להלן..5 קיימות שתי חלופות שונות לפתרון הטכנולוגי בעזרתו תמומש המערכת: מסופים המחוברים למחשב מרכזי רשת מחשבים אישיים. חלופות אלה מתוארות באופן כללי בסעיף 3.0 להלן ובשאר רכיבי פרק 3 במפורט סוף דוגמא למערכת זו דרישות אמינות ואבטחת מידע גבוהות ומחמירות. ראה פירוט דרישות אלה ברכיבים 2.19 ו להלן. לקוח\מומחה יישום סביר שהמערכת מיועדת בעיקר ליחידה מסוימת בארגון. יחידה זו היא בעלת המערכת בכל המשמעויות העסקיות והניהוליות הרלוונטיות, כולל אחריות על המידע, מועדי הפעלת המערכת וכו'. תאר יחידה זו: תפקידיה, סמכויותיה, תחומי פעילותה וכו'.

5 עמוד 5 מתוך יעדים סביר גם שיחידה זו היא אשר תעמיד את מומחה היישום אשר ישתתף באופן פעיל באפיון ובבדיקות המערכת. ציין מי מומחה היישום אשר ילווה את האפיון ומי המומחה אשר ילווה את שלב הבדיקות והתחזוקה השוטפת. שים לב שכלל המשתמשים במערכת מוגדרים ברכיב 2.2 והגורמים המעורבים בפרויקט, ברכיב 4.1 להלן. מומלץ מאד שמספר מומחי היישום יהיה נמוך, 1-2 אנשים. מספר גבוה מזה, מעורר שאלה לגבי מי בעצם מוסמך להחליט לגבי תכני המערכת ולאשר את הפרויקט. עם זאת, לעתים אין מנוס מהקמת נציגות משתמשים רחבה, כתוצאה ממבנה ארגוני מסוים )ארגון מבוזר, למשל(. במקרה זה, יש להקפיד על היררכיה ברורה בין מומחי היישום ונציגות המשתמשים, הן בליווי הפרויקט והן באישורים לקוח \ משתמש עיקרי היחידה בארגון שהיא הנשוא העיקרי של המערכת )היחידה הנושאית( והבעלים שלה. ציין את: שם היחידה יחידת האם מבנה פנימי יעדים ומטרות סמכויות ותחומי אחריות. מבנה כללי של הארגון )המשרד, החברה( מוגדר בסעיף 1.4 להלן. מומחה)י( היישום לכל מומחה-יישום המעורב בפרויקט, ציין: שם תפקיד ושיוך ארגוני כתובת, טלפון, פקס, מידת המעורבות: באילו שלבים, באילו רכיבים. מומחים אחרים )אינם מעורבים רשמית, אך אפשר להסתייע בהם( היו מעורבים בעבר מומחי יישום במערכות שכנות. צוותי משתמשים בפרויקטים גדולים, בהם מעורבים לקוחות שונים ובעלי עניין, יש לעתים צורך להרחיב את מעגל מומחי היישום ולצרף להם צוותיי משתמשים. יש להגדיר מפורשות כפיפויות בהתאם לסעיף לעיל.

6 עמוד 6 מתוך יעדים 1.2 יעדים ומטרות יש להבחין בין יעדים - שהם ברמה עקרונית, לבין מטרות - שהן ברמה מעשית הניתנות לכימות ומדידה. להגדרה מדויקת. בהגדרת המטרות יש להיזהר מכפילות וחזרה על רכיבים מעשיים יותר כגון 2.3 ו אם טרנזקציות המערכת, למשל, מגדירות בברור גם את המטרות, יש לקצר בסעיף זה ולהפנות מכאן לסעיף 2.6! )ובסעיפים שם, יש להפנות חזרה לסעיף זה ע"מ לוודא שכל המטרות והיעדים ממומשים, ראה שם(. הגדרה ברורה של יעדי המערכת ומטרותיה עשויה לשמש בסיס לבניית המערכת במספר מהדורות! יש להדגיש מטרות מינימום למהדורה הראשונה. נסה להגדיר גם יעדים ומטרות שמראש לא ייכללו במהדורה זו. נושא המהדורות עשוי להיות תקף גם לגבי האפיון עצמו: מה יאופיין כעת במפורט ומה יאופיין באופן כללי בלבד. יעדים כלליים רשימה ותיאור קצר סיווג היעדים לפי קריטריונים, כגון: יעדים ראשיים ומשניים יעדים לטווח הקצר/הבינוני/הארוך יעדים שימומשו במהדורה זו ויעדים למהדורות הבאות מטרות מעשיות רשימה ותיאור קצר.1.2 סיווג המטרות לפי מספר קריטריונים, כגון: חשיבות ותועלתיות המדד ושיטת המדידה הערכת המאמץ ואפשרויות המימוש בטווח הקצר והבינוני חיתוך בין תועלת וחשיבות למאמץ ולמידת האפשרות המימוש; עדיפות ברורה למטרות חשובות וקלות לביצוע. מטרות בעדיפות שניה. מטרות שאינן כלולות במהדורה הנוכחית )זו שמאופיינת כאן(, אך הן מועמדות לביצוע במהדורה/גרסה המיידית הבאה )שתבוא מיד לאחר הנוכחית(. מטרות עתידיות לביצוע במהדורות עתידיות )מעבר לנוכחית + הבאה( לאפיון במהדורות עתידיות )מעבר לתיק אפיון זה( בעיות מערכת מידע טובה היא מערכת המקיימת את התנאים הבאים: 1. פונקציונאלית - עונה לדרישות המשתמש/הארגון

7 עמוד 7 מתוך יעדים יעילה - איכותית ובנויה נכון מבחינה הנדסית כלכלית - עומדת בגבולות המשאבים ולו"ז שהוקצו חוקית - עומדת בדרישות החוק, מינהל תקין וחוקת הארגון. להסבר מלא ראה הקיט מודל מפת"ח, סעיף מדדי איכות. גם הבעיות שהמערכת מיועדת לפתור נופלות באחד או יותר מהתחומים הנ"ל. עם זאת, יש הבדל מהותי בין התחום הראשון לבין השאר, 2 ו- )4 3 הוא מקרה מיוחד(. בעיות בתחום 2 ו- 3 הן בעיות פנימיות טכניות של המערכת ואופייניות למהדורות שיפור למערכות קיימות. בעיות מתחום א' הן המטרה העיקרית, הן היעד המרכזי של מערכות מידע בכל ארגון! בעיות בתחומים 2 ו- 3 הן חשובות בעיקר במידה שהן גורמות לבעיות בתחום הראשון. בעיות בתחום הפונקציונאלי )1( הן בעיות בתפקוד הארגון כגון: מתן שירות )במונחי זמינות, איכות וכו'( כ"א מיומן סרבול תהליכים אמינות הפסד כספי חוסר תקשורתיות )אישית( חוסר בקרה וכו'. הטענה הקלאסית בדבר חוסר מידע זמין אינה בעיה, אלא במידה וחוסר זה גורם לאחת מהבעיות הנ"ל, היינו, לתפקוד לקוי של הארגון. בעיות טכניות/הנדסיות פנימיות )ויעילות כנ"ל( במערכת עצמה, כולל בעיות תפעוליות, יכולות להיות במגוון רחב כגון: נפילות והתאוששות לקויה ביצועים לקויים ודרישות משאבים גבוהות תפעול כבד ומסורבל כ"א רב בתחזוקה )בעיה או סימפטום של בעיה אחרת?( קושי בהכנסת שינויים ובלימוד המערכת חוסר במילון נתונים חוסר תקשורתיות )טכנית( ארכיטקטורה מיושנת )יש לנמק ולאושש במספרים!(. בעיות בתחום זה הן, כאמור, משניות. חשיבותן עולה ככל שהן משליכות על פונקציונאליות המערכת או אם הן גורמות להטיה משמעותית בעלות/תועלת המערכת. בסעיף זה יש נטייה מוצדקת במידת-מה להתייחס למצב הקיים. אך אין להגזים ואין להפוך סעיף זה לתיאור המערכת הקיימת. ככלל, תיאור מצב קיים איננו מטרה לעצמה, אלא במידה שהוא תורם לאפיון המערכת )המהדורה( החדשה. במקרה זה, מקומו הוא ברמת כל רכיב ורכיב להלן. הערה זו

8 עמוד 8 מתוך יעדים נכונה בפרט במקרה שהאפיון הוא למהדורה N+1, וקיימת כבר מהדורה N עובדת. מהדורה N היא המצב הקיים ותיק התחזוקה שלה הוא תיעוד המצב הקיים! אחרי כל ההנחיות הנ"ל, זכור שלעתים קרובות בעיות ומטרות הן שני צדדים של אותה מטבע. מנע אפוא כפילות וחזרה על הרכיב הקודם. תמצית הבעיות במצב הקיים סיווג לפי פונקציונאלי, יעילות )הנדסי/טכני(, כלכליות, חוקיות סיווג לפי חריפות הבעיה, היקף הנזק מידת ישימות הפתרון: קל/בינוני/קשה. במונחים של: משאבים, לו"ז, השתלבות בארגון ועוד, לפי המקרה הנדון. אין הכוונה כאן להגדרת מימוש המערכת במלואה. לכך מיועד רכיב 4 להלן. בעיות החוזרות על עצמן בעיות שהמערכת פותרת/אמורה לפתור סיווג לפי סעיף לעיל בעיות שהמערכת יוצרת/עשויה ליצור סיווג לפי סעיף לעיל בעיות שיידחו בעיות שהמערכת )מהדורה זו של המערכת( אינה אמורה לפתור: סיווג לפי סעיף לעיל. הקשר הסיבה מדוע לא מטופלת במהדורה זו. \ ארגוני עסקי הקשר בין מערכת זו )ויעדיה( לבין יעדי הארגון ומטרותיו הוא חשוב ביותר, אך אין להפוך רכיב זה למסמך יעדי הארגון. יש לצרף תקציר של יעדי הארגון ולהפנות למסמך מפורט יותר )מקור(. אם אפיון זה הוא אפיון מהדורה חדשה למערכת קיימת, בדוק היטב אם לא חלו שינויים בסעיף זה מזמן אפיון המהדורה הקודמת או מזמן שהמערכת החלה בפעולתה. לגבי המבנה הארגוני, רצוי שתרשים זה ירשם כבר בקודיפיקציה מתאימה )משתמשים וכו', ראה נושאים תומכים. ודא שבתרשים בכרך בקיט כתיבת תיעוד קודיפיקציה - הפרק סימול ישויות מופיעים בבירור: הלקוח והיחידה הנושאית )רכיב 1.1( כלל המשתמשים )רכיב 2.2( יחידת המחשוב. שים לב שהקשר לתכנית אב למחשוב )תכנון אסטרטגי( הוא ברכיב זה )1.4.1(. קשר זה הוא רשות, בעוד שהקשר עם תכנית העבודה השנתית המופיע ברכיב הבא )1.5( הוא חובה.

9 עמוד 9 מתוך יעדים עבורה נבנית יעדי הארגון, אסטרטגיה תקציר ו/או הפניה למסמך המפרט את יעדי/חוקת הארגון וליחידה הארגונית המערכת )מחלקה, מדור וכו'(. אם נערכה לאחרונה תכנית אב למחשוב, מה הקשר למערכת זו? תרשים ומבנה ארגוני רשימה פשוטה )ספר טלפונים( ו/או תרשים מבנה ארגוני. סימון בצבע על התרשים איפה נוגעת המערכת. השלכות או"ש נושאי או"ש עקרוניים הנוגעים למערכת זו. נושאי או"ש פרטניים הקשורים לאופן הכנסת המערכת לפעולה והטמעתה, מפורטים בסעיף 4.7 להלן. תכנית עבודה שנתית במשרדי הממשלה יש הבחנה ברורה בין תוכנית עבודה שנתית, לבין תוכנית אב למחשוב - תכנון אסטרטגי, שהם מונחים זהים במפת"ח תוכנית עבודה שנתית )תע"ש( למחשוב נגזרת מתקציב המשרד )תקציב המדינה( והיא חובה. תע"ש מתוארת במפורט בקיט מיוחד בשם זה בכרך ניהול כולל. כיון שתע"ש מתארת פרויקטים, כולל פרויקטים רב-שנתיים, יש צורך, במקרים כאלה, )בממשלה( לקבל, בנוסף לתקציב השוטף, גם הרשאה להתחייב. אך בעקרון תע"ש היא תכנית שנתית. תוכנית אב למחשוב מתבצעת אחת למספר שנים )בד"כ 5 שנים( והיא רשות. תכנית אב היא רב- שנתית ומתוארת בקיט מיוחד בשם זה בכרך ניהול כולל. כאמור, תכנית עבודה שנתית היא חובה וחייבת להתבצע פעם אחת )לפחות( בשנה במסגרת הכנת התקציב השנתי, בעוד שתכנית אב למחשוב היא רשות. לפיכך רכיב זה הוא חובה ואילו הרכיב הקודם )1.4( הוא רשות. עם זאת, בארגונים שסיימו לאחרונה ביצוע תוכנית אב למחשוב חובה למעשה להצביע על קשר ברור בין מערכת מידע זו לבין תכנית האב. חשוב לבדוק אם בתכנית העבודה השנתית הוגדרו מערכות שיש להן קשר עם מערכת זו ואם קשר זה יוצר תלות הדדית שיש להתחשב בה אישור )סימוכין( תקציבי / עסקי ליחידות מחשב: קישור ברור לתכנית העבודה השנתית המאושרת ולתקציב של יחידת המחשוב. במערכות מידע ממשלתיות - סעיף זה הוא חובה. במידה שמערכת המידע איננה תואמת את תכנית העבודה השנתית המאושרת לארגון, יש להביא סימוכין לנחיצות המערכת מוועדת ההיגוי למחשוב. לחברות מחשבים ובתי תוכנה: חוזה או הזמנת עבודה מהלקוח ואישור הנהלת החברה. בפרויקטים גדולים, יש להקפיד על תקצוב רב שנתי )הרשאות(, בנוסף לחלק המתוקצב בשנה הנוכחית. )בתי תוכנה: התחייבות רב שנתית של הלקוח(.

10 עמוד 10 מתוך יעדים תלות במערכות אחרות מערכות אחרות )מידע ותשתית( שמופיעות בתוכנית העבודה השנתית או כבר בפיתוח שהמערכת הנדונה תלויה בהן. אין לכפול תת רכיב זה עם רכיבים , ו כאן הכוונה לתלות תקציבית, תלות הנובעת מתכנית הפיתוח הכוללת )תכנית העבודה( של הארגון. ישימות ועלות/תועלת נסה לכמת את התועלות והחסכונות הצפויים. תועלות נמדדות ביחידות שירות שהמערכת מפיקה. חסכונות נמדדים במשאבים של: כסף, כ"א, זמן, חומרים כלים וכו'. ציין את שיטת המדידה המומלצת למדידת תועלות/חסכונות אלה. במידה שקשה לכמת את התועלות, הנח הנחות אשר יאפשרו כימות בשלב מאוחר יותר. בדוק אילו השלכות יש למידע הנכתב בסעיף זה על הערכת עלות המערכת )פרק 5 להלן(, בפרט בהקשר עם חסמים - עליון ותחתון - לעלות המערכת. היעזר בהרחבה לרכיב 1.6: ישימות ועלות/תועלת בגלופת הלימוד של עץ מערכת אוניברסלי בקיט עץ מערכת. )עיין גם בקיט ניתוח חלופות שבכרך נושאים תומכים(. כתוב סעיף זה בסוף האפיון. סעיף זה הוא דוגמא מובהקת לכך שסדר הופעת הרכיבים בתיק )בעץ המערכת( איננו בהכרח סדר כתיבתם, בוודאי לא סדר העבודה סיכונים - ישימות הפרויקט בחן את המערכת\הפרויקט מול פרויקטים דומים בארגון ומחוצה לו סקר סיכונים שנתי הוא חובה בפרויקטים גדולים ומתמשכים. ראה קיט ניתוח סיכונים בכרך נושאים תומכים. עלות/תועלת ישימות עסקית עלויות )תמצית מרכיב 5.0 או רכיב 5.5( אופק תועלות וחסכונות הניתנים למדידה )כימות של רכיב 1.2(: התועלת או החיסכון יחידת המדידה כיצד ניתן למדוד לפני ואחרי מימוש המערכת או הכנסת שינוי תצפית בפועל. תועלות וחסכונות בלתי ניתנים למדידה )מתחרים, שינויים צפויים(. עלות מול תועלת: טבלה או נוסחה הזמן ברירת המחדל לטווח הזמן בו מיועדת המערכת לפעול, היא 5 שנים. בפרק זמן זה יש לקחת בחשבון שתים עד שלוש מהדורות או יחידות מסירה נוספות, בנוסף לתחזוקה שוטפת של תיקון שגיאות ושינויים כפויים.

11 עמוד 11 מתוך יעדים יש להימנע מפירוט יתר ברכיב זה. לתכנית עבודה מפורטת ומועדים מדויקים מיועד רכיב 4.2 )ו- 4.3( להלן. ברכיב זה )1.7( יצוינו שלושה תאריכי יעד, כמפורט בהמשך, במטרה להתוות מסגרת זמן כללית לפרויקט. תוצרים מהדורה \ יחידת מסירה ראשונה )הבאה( של המערכת מותקנת ועובדת מהדורה \ יחידת מסירה שנייה )עוקבת( של המערכת מותקנת ועובדת סיום הפרויקט, השלמת כל המערכת מועד נטישה מועד קריטי שמעבר לו אין טעם בהתקנת המערכת ועדיף לנטוש את הפרויקט משך חיי המערכת התקופה התפעולית של המערכת עד שסביר שתוחלף יעדים פתוחים )חלופות( סעיף זה מטרתו לרכז את כל הנקודות שנשארו פתוחות ברכיב היעדים. נקודות פתוחות הן לעיתים קרובות חלופות )אלטרנטיבות( אפשריות ולפיכך גם החלופות השונות תתועדנה כאן. ראה קיט ניתוח חלופות בכרך נושאים תומכים. יש לבדוק היטב את שני המקרים הבאים: )X.1( נקודות פתוחות )וחלופות( ברמת רכיב משני חלופה מקיפה לרכיב היעדים בכללותו. שני מקרים אלה, שהם השכיחים יחסית, לא יתועדו למעשה ברכיב זה. נקודות פתוחות וחלופות ברמת רכיב משני - מקומן ברכיב המשני )98.X.1(. חלופה מקיפה לרכיב היעדים כולו - תתואר ע"י תיעוד חוזר ומלא של רכיב 1 כולו ) (. - רכיב זה מיועד אם כך, למקרי ביניים, היינו, מקרים בהם החלופות והנקודות הפתוחות הן כלליות ואינן משנות את הגדרת היעדים כפי שתועדה ברכיבים לעיל. בכל מקרה, חיוני לסגור סופית את הנקודות הפתוחות ולהכריע בין החלופות השונות ברכיב היעדים, חשוב ביותר להשאיר בתיק תיעוד גם לנקודות אחרת המשך אפיון המערכת כולו תלוי על בלימה. שנסגרו ולחלופות שנדחו, על מנת לסייע בדיונים מחודשים בעתיד. הנקודות הפתוחות יזוהו באופן הבא: הנקודה-הפתוחה/חלופה: שם או זיהוי אחר תאריך פתיחה תאריך סגירה הגורם שסגר / מסמך המתאים הפניה לסיכום דיון

12 עמוד 12 מתוך יעדים 1.99 יעדים עתידיים סעיף זה מטרתו לרכז את כל הדרישות העתידיות ברכיב היעדים שאינן כלולות במהדורה הנדונה, אך סביר שיכללו במהדורות עתידיות. רישום דרישות עתידיות אלה, הוא במטרה כפולה: לא לאבד מידע קיים להדגיש מה לא כלול במהדורה הנדונה ולסייע בכך לניהול תצורה של המערכת. מיקומן של דרישות עתידיות אלה ברכיב ראשי )פרק 1( של עץ המערכת, הוא מכוון. אם יש מספיק מידע וצורך לרשום תחזיות אלה ברמה מפורטת יותר, היינו, ברכיבי יעדים משניים )X.1(, יש לבדוק היטב אם אין לפנינו בסיס להגדרה של המהדורה הבאה של המערכת. הגדרה כזו פירושה תיעוד מלא של רכיב 1 כולו ומיקומו בתיק אפיון נפרד )של המהדורה הבאה(. לרכיב זה יש השפעה רבה על רכיבים מקבילים )99.X( ולכן יש ללבן אותו ולסגור אותו בהקדם האפשרי. אופן תיעוד הדרישות: שם או זיהוי אחר. תיאור הדרישה או הפניה לתיעוד אחר )תכנון אסטרטגי למשל( קשר לרכיבים 99.X אחרים הפניה לסיכום דיון.

13 עמוד 13 מתוך יישום - מהות המערכת. 2 - י י ש ו ם 2.0 מ ה ו ת ה מ ע ר כ ת המטרה העיקרית של רכיבי פרק זה היא לוודא שהיישום, מהות המערכת, מכוסה על כל היבטיו. סדר הרכיבים: , 2.1, וכו', הוא במידת מה שרירותי ובודאי שאין הוא קובע את סדר הגדרת הרכיבים ובנייתם. כל פרויקט יתחיל ברכיב שנוח לו, יזהה את הרכיב המוביל, יעבור משם לרכיבים האחרים וינוע ביניהם הלוך וחזור בשיטה של הגדרה סיבובית והדרגתית. לרכיב 2.20 חיתוכים והצלבות יש חשיבות רבה, לא רק כרכיב מסכם ומאבטח איכות, אלא כרכיב אשר מלווה את אפיון המערכת בזמן אמת ושומר כל הזמן על איזון ויחסי גומלין בין הרכיבים השונים. ישנן מתודולוגיות פורמליות שהולכות בשיטה זו שנקראת.Cross reference Analysis שיטה זו יכולה להצליח בעיקר בשילוב עם כלי ממוחשב. קשה מאד לנהל אותה ידנית. למרות החלוקה השרירותית מה, אפשר לזהות תת קבוצות ברורות בתוך רכיב היישום: מסגרת ותיחום כללי של המערכת )חיצוני ופנימי( - רכיבים ממשק המשתמש - רכיב 2.4 מגדיר את האופן בו המשתמש רואה את המערכת ועובד אתה. כללים עסקיים - רכיבים מגדירים את הכללים לפיהם פועלת המערכת. חלק זה נקרא גם המודל הדינמי של המערכת או החלק האלגוריתמי. ביחד עם רכיב 2.4 לעיל, הקבוצה הכוללת, 2.10, מגדירה את אופן פעולת המערכת ואת צורת העבודה איתה. מידע שהמערכת מנהלת - רכיבים מגדירים זאת וכן מידע תומך שהמערכת נעזרת בו. חלק זה נקרא גם המודל הסטטי של המערכת או בסיס המידע. רכיב 2.10 מופיע פעמיים גם בקבוצת המודל הדינמי וגם בקבוצת המידע המודל הסטטי. יש לרכיב זה אכן נשמה כפולה. ראה הסבר נוסף ברכיב עצמו להלן. פרמטרים אורתוגונליים - רכיבים מגדירים פרמטרים החותכים את הקבוצות הקודמות ומתארים תכונות כלליות של היישום, כגון: ממשקים, אבטחת מידע ועומסים. חלוקה זו, בעיקר שלוש קבוצות הביניים: ממשק משתמש, כללים עסקיים ומידע, תואמת את רוב המתודולוגיות והשיטות לניתוח מערכת המקובלות ומאפשרת קישור לוגי ופיסי של פרק היישום עם כלים ומתודולוגיות מתקדמים להנדסת תוכנה CASE).(Software Engineering, ארכיטקטורה הבהקים כללית אפשר, בשלב ביניים, לכלול ברכיב זה )בדומה לרכיב 1.0 לעיל(, נושאים ודגשים כלליים של היישום, שחשוב לזכור אותם אך מקומם הסופי לא ברור. במהלך בניית התיק יועברו נושאים אלה למקומם הטבעי - אחד הסעיפים בפרק זה )X.2( או בפרקים הבאים. בשום פנים ואופן אין להפוך רכיב זה לתיאור המערכת כולה! לכל מידע המופיע כאן יש מקום טבעי וברור בפרקים ובסעיפים שלהלן. בצורתו הסופית, יכיל רכיב זה אך ורק עקרונות יסוד, תפיסה כללית וכו', נושאי יישום אשר חשוב להדגישם, במבנה של הבהקים )Highlights( ולפי הדוגמא להלן. זכור שסעיף זה יופיע בד"כ בתמצית מנהלים שתופק מתיק זה. ראה קיט תיעוד בכרך נושאים תומכים. דוגמא: )בלבד!(.5 המערכת המאופיינת היא המשך של מערכת קיימת. המצב הקיים לא תועד בנפרד, אך אפיון זה מתחשב בכל הידע שהצטבר במערכת הקיימת, פרט בממשקים עם מערכות מידע חיצוניות. ראה פירוט בסעיפים 2.1 ו להלן.

14 עמוד 14 מתוך יישום - מהות המערכת.4.5 חלוקת המערכת ל- 2 תת-מערכות מרכזיות, תת-מערכת א' ותת-מערכת ב', מודגשת מאד לאורך תיק האפיון. מומלץ ביותר להשתמש בחלוקה זו לבניית המערכת בשתי מהדורות. ראה חלוקה פונקציונלית של המערכת ברכיב 2.3 שלהלן. לקובצי המערכת יש שתי תכונות חשובות: מידת הפירוט, ראה רכיב 2.11 להלן. נפח רב, ראה רכיב 2.21 להלן. בעיצוב המערכת ובנייתה יש לקחת בחשבון שתי תכונות אלה..6.7 סוף דוגמה לממשקי אדם-מחשב חשיבות רבה במערכת. המלצה ברורה לשלב העיצוב היא בניית המסכים לפי תקן 11.X ראה פירוט ברכיב 2.4, להלן. המערכת מושתתת על הגדרה ברורה של ישויות המידע הבאות: חוזה מספר קטלוגי חשבון ספק סופי. ראה הגדרה מלאה של ישויות אלה ואחרות בסעיפים , להלן. מאפיינים כלליים מצב קיים בתיעוד רכיב זה יש מספר אפשרויות, מהקל אל הכבד: הפנייה לרכיב 1.3 בעיות. התיעוד שם, ברמת או סעיף 1.3 כולו, מספק. אין צורך להרחיב כאן. סקירה קצרה של המצב הקיים כאן. התיאור ברכיב 1.3 לעיל איננו מספק. אפשרות זו היא המקרה הקלאסי של שימוש ברכיב זה. סקירה יסודית ונרחבת של המצב הקיים כאן. יש לצרף לתיק נספח 2.1.1: מצב קיים. ראה ' ועבודה בלשונית תוצרים בקיט זה. תיק מצב קיים: במקרים קיצוניים יותר בהם נדרש תיק מצב קיים, יש לפעול כמוסבר במדריך המלא ולהוציא תיעוד עץ מערכת מלא של המצב הקיים. למידע נוסף, בעיקר בהקשר עם שני המקרים האחרונים, ראה הרחבה לרכיב מצב קיים ב בקיט עץ מערכת אוניברסלי בכרך מחזור חיים. אופי המערכת וסוגה ציין את אופי המערכת המתוכננת, באופן כללי, האם היא: חדשה לגמרי, ללא כל זיקה למערכת קיימת )ידנית או ממוכנת( חדשה, אך בזיקה חלשה למערכת קיימת )ידנית או ממוכנת( הרחבה של מערכת קיימת )מעבר למהדורה חדשה(

15 עמוד 15 מתוך יישום - מהות המערכת חדשה אך דומה למערכת אחרת: במשרד, במשרדים אחרים וכו'. מה הוא סוג המערכת המתוכננת, באופן כללי, האם היא: מערכת רישומית מערכת תפעולית מערכת בקרה מערכת תכנון ומעקב מרכז מידע center( )information שירות ישיר למשתמשי קצה מערכת משובצת מחשב מערכת זמן אמת אחר. יחידות צה"ל יסווגו את המערכת עפ"י סיווגים נוספים המוגדרים בהוראות צה"ל/מקשר"ר/מצו"ב/במ"מ. מה סוג הפעילויות הצפויות במערכת. האם רוב הפעילויות תהיינה מסוג: Batch )אצווה( ) Online Transaction Processing מקוונות )טרנזקציות OLTP Data entry )הזנת נתונים( פעולות Housekeeping )פתיחת/סגירת שנה( שימוש בכלים למשתמש קצה,DSS( גיליון אלקטרוני וכו'( ממשקים בזמן אמת )סיגנלים( עם מכשור אחר אחר. אילוצים אילוצים ומגבלות יישומיים כלליים המשפיעים על אופיה הכללי וסיווגה של המערכת, כגון: אילוצי חוק וחוקת הארגון, תקינה ומדיניות. אתיקה ונורמות מקצועיות דרישות סקטוריאליות מערכות קיימות בארגון וחוצה לו, סביבה טכנית קיימת או מתוכננת, אילוצים כלכליים, ביחידות צה"ל: אילוצי במ"מ. לפי הנחיות צה"ל/מקשר"ר/מצו"ב/במ"מ.

16 עמוד 16 מתוך יישום - מהות המערכת אילוצים אחרים בתחומי הטכנולוגיה, היישום, כוח אדם, עלויות, מימוש )לו"ז( וכו' יצוינו להלן בסעיף המתאים! מילון מונחים במילון מונחים יש לקטלג מונחים ומושגים כלליים שהם שפת הארגון )שפת המערכת( ושהדרך הנוחה להסבירם ולהגדירם הוא במלל חופשי. סביר שבשלבים המוקדמים של האפיון יכיל רכיב זה הגדרות שבשלבים מאוחרים יותר )של האפיון!( אכן יועברו לרכיבים קונקרטיים יותר בקבוצה הנ"ל נקודות לשיקופים ולאבטחת איכות: כמה מונחים מכיל רכיב זה בסוף האפיון? העברת מונחים מרכיב זה לרכיבים הקונקרטיים בשלב העיצוב - התרעה! בתיק האפיון הסופי, יכול רכיב זה להיות במספר תצורות: תצורה מינימלית: רק מונחים שלא מצאו את ביטויים ברכיב קונקרטי. תצורה מקסימלית: כל המונחים והמושגים של שפת המערכת. אלה שיש להם ביטוי קונקרטי תצוין לידם הפניה מתאימה. תצורת :Hypertext אם יוחלט להפוך את תיק האפיון למסמך.Hypertext זכור שרכיב זה עשוי גם להילקח, ברמה זו או אחרת, לתמצית המנהלים! הגדרת מונח תכיל: 2.2 טקסט חופשי. קישור לרכיב קונקרטי תיחום חיצוני רכיב זה חשוב ביותר לתיחום גבולות המערכת: עם מי יש למערכת קשר, היכן מתחילה ונגמרת המערכת, מי ישתמש בה באופן שוטף. רשימת המשתמשים תהיה מלאה גם אם זו חזרה על המשתמש העיקרי ברכיב 1.1. לכל משתמש/מערכת מידע יש להגדיר: האם הוא ספק מידע,)Source( צרכן מידע )Destination( או שניהם? מידת חיוניות המערכת לעבודתו השוטפת, נימוק! תיאור קצר של המידע, כולל תדירות הגישה ובאילו תקופות? שים לב לקשר של רכיב זה עם רכיב אבטחת מידע. לכל משתמש הרשום כאן, צריך שתהיה גם הגדרה של הרשאה ומידור מתאימים שם. הקבצה של משתמשים ומערכות מידע תיתכן במספר רמות, בהתאם להבנת המאפיין, המצב בשטח ומידת המעורבות של מומחה היישום. למשל, אפשר לציין מחלקת הנהלת חשבונות, או לרדת לרמה מפורטת יותר )מדור, רמה אישית(. או אפשר לציין מערכת המידע של מנהל הכנסות המדינה, או מערך מע"מ, או לרדת לרמה מפורטת יותר. זיהוי המשתמשים יכול להיעשות ע"י סימול )מספרי( או ע"י זיהוי שמי )או צרוף של שניהם(. סימול הוא בהחלט רצוי. אם קיים סימול ברור של משתמשים בארגון, יש לפעול לפיו. אם אין, יש ליצור

17 עמוד 17 מתוך יישום - מהות המערכת סימול כזה. היעזר בפרק סימול ישויות - קודיפיקציה בקיט תיעוד שבכרך נושאים תומכים. רצוי לבחור בזיהוי לפי מספר רץ ולא ליפול במהמורה של היררכיות ומבנה ארגוני. אפשר גם להסתפק בזיהוי שמי, אך הוא חייב להיות ברור. בכל מקרה, הזיהוי יהיה פונקציונאלי לפי תפקיד ומיקום בארגון ולא אישי. בכל שיטה שתבחר, חשוב שיהיה אפשר להצליב משתמשים עם ישויות חשובות אחרות )ראה רכיב/סעיף 2.20 להלן( תיחום כללי דוגמא לכלי לשימוש ברכיב זה:.DFD Context Diagram משתמשים משתמשי פנים, לפי מבנה ארגוני משתמשים חיצוניים לארגון מערכות משיקות מערכות )מידע ותשתית( פנימיות בארגון מערכות )מידע ותשתית( חיצוניות לארגון אזכור המערכות המשיקות כאן הוא למטרת השלמת התיחום החיצוני של המערכת. פירוט הממשקים של המערכת עם מערכות אחרות, פנימיות וחיצוניות, מקומו ברכיב 2.22 ממשקים וקישורים להלן. תיחום פנימי הבאים הם חטיבה לוגית אחת, המתייחסת לחלק האלגוריתמי של 2.3 שים לב שסעיפים המערכת, כאשר: רכיב 2.3 מיועד לפירוק פונקציונלי ולתיחום כללי )בהמשך לרכיב 2.2( רכיבים 2.4 )מסכים( ו- 2.6 )טרנזקציות( הם המשך לוגי של רכיב 2.3 )והם מקבילים רכיב 2.11 המייצג את צד הנתונים( רכיב 2.5 )תהליכים( הוא שרשרת של טרנזקציות רכיב 2.7 )מודולים( הוא המימוש הפיסי )בעיקר של רכיב 2.6(. מכאן שכל הרכיבים הנ"ל משולבים זה בזה ובהגדרת כל רכיב חשוב להציג את קשריו עם הרכיבים האחרים. לעתים, הקשר בין הרכיבים )למשל הקשר של רכיב משתמשים, עם רכיב 2.3( הוא הדוק במידה כזו שמוצדק לאחד את הגדרתם. איחוד כזה מותנה במהות המערכת הספציפית, אך גם בכלי ובטכניקה שבשימוש. קיימות שיטות וטכניקות שונות כיצד להגדיר חלוקה פונקציונאלית )פירוק פונקציונאלי( של מערכת מידע. מפת"ח, כנוהל-מסגרת פתוח, איננו מכתיב שיטה וטכניקה זו או אחרת. בהגדרת רכיב זה ותיעודו אפשר, אפוא, להשתמש בכל טכניקה מוכרת ומקובלת לפירוק פונקציונלי, בפרט אם היא נתמכת בכלי ממוכן. אין עדיפות לטכניקת Top/down אוBottom/up, להצגה בתרשים או במלל. הצגת המערכת,Top/down למשל, אין פירושה שהמערכת הוגדרה - או חייבת להבנות -.Top/down

18 עמוד 18 מתוך יישום - מהות המערכת שים לב שטכניקות מסוימות מגדירות יחד עם הפירוק הפונקציונאלי גם רכיבים נוספים, דוגמת: משתמשים, קבצים, ממשקי העברת מידע וכו'. אין מניעה מלהשתמש בטכניקות אלה ובלבד שהרכיבים הנוספים יופיעו גם ברכיב המתאים לפי עץ המערכת. הפתרון הטכני לכפילות זו הוא כמובן השימוש ב- repository )ראה רכיב 3.12( ובמחולל תיעוד מתאים, המאפשרים להציג את תכני ה- repository לפי סרגל תיעוד המוכתב לכלי מבחוץ. הדגש ברכיב זה הוא על פירוק פונקציונאלי כללי! אין להיסחף, ברכיב זה, לפירוק מפורט המגיע עד רמת טרנזקציה ו/או מסך. לשם כך מיועדים רכיבים , ו- 2.6 הסמוכים. באשר למידת הפירוט של רכיבים אחרונים אלה, בשלב האפיון, ראה הנחיות שם. שים לב שבהגדרת רכיב זה אפשר כבר להניח את היסודות לניהול תצורה של המערכת, היינו הגדרת מהדורות לבנייתה ואפשר גם לאפיונה. כל תת מערכת תהיה יחידה אוטונומית לניהול תצורה,CSCI( במונחי.)A2167-DOD הקפד על ציון הקשרים והתלויות בין תת-המערכות בחלוקות שהוגדרו. ציין אלו מהחלוקות הנ"ל )לתת-מערכות( ניתנות לביצוע כפרויקטים נפרדים, במקביל או בשרשרת ובאילו עדיפויות וסדרי קדימויות. תיאור כללי של המערכת הסבר כולל בתרשים כגון DFD 0 ומקרא קצר חלוקה לתת מערכות ראשיות: דרוג לפי: מורכבות, קדימויות ועדיפויות, חלוקה למהדורות \ יחידות מסירה \ לתת-פרויקטים תת-מערכת \ יחידת מסירה 1 הסבר כולל בתרשים כגון DFD 1 ומקרא קצר פונקציות ותהליכים ראשיים שים לב, פירוק ופירוט נוסף של תת המערכת יהיה באמצעות סעיפים 2.5 ו- 2.6 להלן. מקובל במפת"ח להקדיש את תת המערכת הראשונה )לעתים גם השנייה, אם יש צורך( לתת המערכת המנהלת, המספקת שירותי שליטה ובקרה וכן מנגנונים רוחביים משותפים )טיפול בשגיאות וכדומה( לשאר תת המערכות. תת-מערכת \ יחידת מסירה 2 הסבר כולל בתרשים כגון DFD 1 ומקרא קצר פונקציות ותהליכים ראשיים N תת \ מערכת יחידת מסירה 2.3.N 2.4 ממשק משתמש יש לבדוק היטב אם קיימים תקנים ארגוניים ותבניות מוכנות למסכי תפריט ופעולה בארגון. ראה הרחבה לסעיף 2.4.0: ממשק אדם מחשב בקיט עץ מערכת אוניברסלי בכרך מחזור חיים.

19 עמוד 19 מתוך יישום - מהות המערכת רצוי מאד להיעזר בכלי ממוכן. אם אפשר, כבר בכלי הפיתוח הסופי )מחולל מסכים( שבעזרתו תיבנה המערכת. קיים הבדל המהותי שבין שלשת תת-הסעיפים להלן: רכיב מגדיר כללי הנדסת אנוש ותקן לעיצוב המסכים במערכת, רכיב מגדיר את מסכי התפריט ואפשר לראותו כהמשך לרכיב 2.3 לעיל רכיב מגדיר את מסכי הפעולה ואפשר לראותו כחלק מרכיב 2.6 להלן. הדגש בשלב האפיון יהיה על סעיפים ו ופחות על הערה זו נכונה בפרט לפרויקטים הבוחרים לבנות אבטיפוס. רכיב מסכי תפריט, אשר נקרא גם עץ המסכים, מתאר את עץ המסכים הכללי והסטטי. עצי מסכים דינמיים וחלקיים, המתארים את המסלולים השונים לפיהם אפשר לטייל בעץ או לעבור ממסך פעולה אחד לשני על מנת לבצע סידרה של פעולות, מתואר ברכיב 2.5 תהליכים הסמוך. בהקשר עם סימול המסכים ראה פרק סימול ישויות - קודיפיקציה בקיט תיעוד שבכרך נושאים תומכים. בשלב ראשון רצוי לתת למסכים סימול עצמאי משלהם: M001, M002 וכו' ולקשר בשלב העיצוב עם החלוקה לתת-מערכות עם החלוקה לטרנזקציות )ובעתיד לאובייקטים(, אפשר להשתמש בקידומת: 2.4.2, 2.4.1, לסימול המסכים. במערכות חלונאיות יש העברת דגש לכיוון מסכי הפעולה ושילוב הניווט והפעולות האפשריות )היינו פונקציות תפריט( בתוכם. בכלל, ההבחנה בין שני סוגים אלה, קצת מתערפלת. אך עדיין יש חלוקה כללית לתפריטים ולמסכי פעולה, בעיקר ברמה הכללית של חלוקת המערכת והניווט בה בגדול וזה מה שחשוב באפיון. מבנה אחיד ותקני כללי הנדסת אנוש כללים ותקנים בממשקי אדם-מחשב:.)Human-Computer Interface( HCI ברמת הארגון )שלדים מוכנים(. מבנה תקני והשתלבות עם רכיבי המערכת האחרים לפי תקן:. בינ"ל/ישראלי כגון: x11 תקן דה-פקטו של יצרן מוביל מסכי תפריט - עץ המסכים מסך ראשי Menu :Home Page / Main מבנה, פונקציות, תכנים \ נתונים, בחירה \ קישורים שרטוט, או הפניה לאבטיפוס \ מודל מוחשי מסכים משניים עיקריים )תפריטי משנה( מבנה, פונקציות, תכנים \ נתונים, בחירה \ קישורים שרטוט או הפניה לאבטיפוס \ מודל מוחשי

20 עמוד 20 מתוך 86 עץ המסכים - map site 2. יישום - מהות המערכת מסכי פעולה לכל אחד ממסכי \ חלונות הפעולה: מבנה, פונקציות, תכנים \ נתונים, בחירה \ קישורים שרטוט או הפניה לאבטיפוס \ מודל מוחשי תהליכים תהליכים מוגדרים כשרשרת טרנזקציות שביצוען ברצף )sequence( מבצע תהליך ארגוני/עסקי אחד. אם טרנזקציה היא האטום, אזי תהליך הוא המולקולה. קיים אפוא קשר הדוק ביותר בין רכיב זה ורכיב הטרנזקציות הסמוך ורצוי להגדירם ביחד. )ההחלטה על הגדרה Top/down אוBottom/up, היינו, קודם תהליכים ומהם לגזור טרנזקציות, או ההפך, קודם טרנזקציות ואח"כ לבנות מהם את התהליכים - היא בידי המשתמש והכלי שבו הוא עובד(. מבין שניהם, יש עדיפות לטרנזקציות )לאטומים( ואם הן מוגדרות היטב ובאופן ברור )כולל קשר למסכים, קבצים וכו'(, יש לשקול היטב את מידת ההשקעה ברכיב זה. זאת, בתנאי שניתן להצביע על התהליך שהטרנזקציה היא חלק ממנו. הסיבה למתן העדיפות לטרנזקציות היא שבמערכת ממוכנת תהליכים ממומשים ע"י טרנזקציות. תהליך הוא רצף לוגי של טרנזקציות המבוצעים תוך התניות וניווט. הרצף, היינו התהליך, נוצר באמצעות סינכרוניזציה בבסיס הנתונים. במלים אחרות, כל טרנזקציה בודקת בתחילת פעולתה את מצב הקבצים עליהם היא מתכוננת לפעול, כולל flags למיניהם, ובהתאם למצב זה מחליטה אם וכיצד לפעול. תרומה עיקרית של רכיב זה היא בכיסוי של טרנזקציות ידניות. במלים אחרות, בתהליכים מודגשות גם פעילויות שאינן ממוכנות והן חלק מהתהליך. תרומה חשובה אחרת היא תיאור המסלולים הדינמיים בין המסכים, היינו אפשרויות הניווט בין המסכים, לעתים גם ישירות ממסך פעולה אחד לשני שלא דרך מסכי התפריט, על מנת לבצע רצף לוגי של פעולות. מסלולי פעולה אלה הם התהליכים. טכניקה מקובלת לתיאור תהליכים היא Block Diagram ומומלץ מאד להשתמש בכלי גרפי התומך בטכניקה זו. טכניקה אחרת היא דיאגרמת ELH: Entity Life History המראה את מחזור החיים של ישות מידע מסוימת. רכיבים 2.5, 2.3, ו- 2.6 מגדירים, ביחד, את החלק האלגוריתמי - המודל הדינמי - של המערכת ברמות שונות של פירוק.(decomposition) חשוב לאזן ביניהם. המלצת מפת"ח היא לייחד את 2.3 לרמת הפירוק העליונה של המערכת, היינו החלוקה לתת מערכות ומנגד, את 2.6 לרמת הפירוק הנמוכה ביותר, היינו לפעולות הבסיסיות ביותר של המערכת האטומים. רכיב 2.5 מיועד לכל רמות הפירוק הביניימיות תהליכים ותת תהליכים. בפועל, האיזון בין שלושה רכיבים מרכזיים אלה ייתכן במספר אפשרויות, מהקל אל הכבד, כדלהלן: מערכת פשוטה מאד. רכיבים 2.3 ו- 2.5 מיותרים למעשה. יש קשר ישיר בין רכיב 2.4 ממשק המשתמש )תת רכיב בפרט( ורכיב 2.6 טרנזקציות. שני רכיבים אלה מכסים למעשה את המודל הדינמי )החלק האלגוריתמי( של המערכת. מקרה מיוחד זה מכוסה בערכה מערכות קטנות שבכרך ניהול פרויקטים. מערכת פשוטה עד בינונית עם חלוקה ברורה לתת מערכות: מרכז הכובד הוא רכיבים 2.3 ו יש קשר ישיר ביניהם )וביניהם ובין 2.4(. רכיב 2.5 מנוון )מפנה אליהם או לא קיים כלל(.

21 עמוד 21 מתוך יישום - מהות המערכת מערכת פשוטה עד בינונית בלי חלוקה לתת מערכות: מרכז הכובד הוא רכיבים 2.5 ו רכיב 2.3 נותן הסבר כללי ותמציתי בלבד ומפנה מיד אל רכיב 2.5. אפשר בעצם להבין את המערכת ישירות מתוך רכיב 2.5 אשר מתחבר לרכיב 2.4 מצד אחד ולרכיב 2.6 מצד שני. מערכת בינונית עד מורכבת: כל שלשת הרכיבים, , ו- 2.6 חשובים כמוסבר להלן. מערכת מורכבת המפותחת במספר מהדורות \ יחידות מסירה: רכיב 2.3 הוא מרכז הכובד )בתיק הראשי של המערכת(. הוא מפנה לנספחים , וכו' או לתיקי תת מערכות )מהדורות, יחידות מסירה( שם נמצא פרק היישום של כל תת מערכת. רכיבים 2.5 ו- 2.6 כמו כל שאר רכיבי היישום )בתיק הראשי( מתארים רק את הרכיבים המשותפים לכל תת המערכות. מקרים מיוחדים אלה מכוסים בערכה פיתוח במספר יחידות מסירה ובערכה מערכות גדולות ותת מערכות שבכרך ניהול פרויקטים. בכל מקרה, יש לשמור על קשר ברור בין רכיב 2.5 ו- 2.3 לעיל. רכיב 2.5 מתחיל במקום שבו רכיב 2.3 הסתיים. השורשים של 2.5 הם העלים של 2.3 )לפי תת הרכיבים \ תת המערכות: , וכו'(. תהליך X.2.5 הוא המשך ישיר של תת מערכת X.2.3. בהתאם לכך, רכיב יפרט את כל התהליכים התומכים במנגנונים הרוחביים של המערכת )ראה תת מערכת לעיל(. פירוק (decomposition) של התהליך ייתכן במספר אפשרויות )רמות(. הפירוק יכול להסתיים כמוצג לעיל ברמה ) (, 3 להמשיך לרמה נמוכה יותר ) ( או להיעצר ברמה גבוהה יותר )2.5.1(. הכל בהתאם למורכבות וסביכות התהליך. בכל מקרה, הרמה הנמוכה ביותר, העלה של עץ התהליכים, תקושר לרכיב 2.6 ודרכו לרכיבים 2.4 ו או ישירות אליהם. הפירוק לא חייב להיות סימטרי לרוחב עץ התהליכים. ענף מסוים יכול להסתיים ברמה 2 )להיעצר ברכיב למשל(, בעוד שענף אחר יכול להסתיים ברמה 4 )רכיב למשל( אינדקס כללי רשימה \ טבלה של כל התהליכים במערכת. לכל תהליך )שורה בטבלה( המאפיינים הבאים: שם וסימול )קישור לרכיב 2.3( סוג רמת פירוק )סופי, בר-פירוק( X תהליך שם וזיהוי סוג:,BATCH אוטומטי, ידני וכו' שיוך פונקציונאלי )קשר ל- 2.3(, תיאור כללי: תרשים )תרשים זרימה,,Block diagram תרשים היררכי וכו'( הגורמים המשתתפים )התחנות בארגון( פירוט ופירוק - הטרנזקציות המשתתפות: ידניות או ממוכנות )קשר לרכיב 2.6!(. תיאור מפורט: מלל מובנה, קשר לקבצים, קשר לאחור למטרות. 2.5.X

22 עמוד 22 מתוך יישום - מהות המערכת Y תהליך 2.5.Y.Xתת 2.6 תיאור מפורט של תת תהליך Y עפ"י המפורט בסעיף לעיל. תיאור במלל טרנזקציות תרשים כגון DFD ברמה 3 אשר אינו מתפרק יותר הפנייה לטרנזקציות המתאימות המרכיבות את תת התהליך ראה תחילה ההנחיות ברכיב 2.3 לעיל וכן רכיב 2.5 לעיל. רכיב 2.5 הדן בתהליכים מכיל גם הגדרה לטרנזקציה. קיימות שיטות וטכניקות רבות להגדרת טרנזקציות במערכת. מפת"ח, בהיותו נוהל-מסגרת פתוח, איננו מכתיב שיטה וטכניקה זו או אחרת. יש לראות אפוא את ההנחיות הבאות כהמלצות בלבד, בחלקן המלצות חמות, כגון שכל טרנזקציה תקבל סימול ברור. חלוקה לטרנזקציות יכולה להיות במספר שיטות: ע"י פירוק פונקציונלי בהמשך ל- 2.3 לעיל ע"י פירוק תפעולי בהמשך ל- 2.4 )עץ המסכים( ע"י המשך הפירוק לתהליכים מהרכיב הקודם )2.5( ע"י פירוק התואם את החלוקה לקבצים לוגיים )רכיב 2.11( ע"י פירוק התואם את החלוקה לישויות המידע )רכיב 2.13( בהתאם לחלוקה למשתמשים )2.2( ע"י שילוב חלקי או מלא של הנ"ל: , 2.3, 2.2, ו- 2.11/2.13 בלי שום היררכיה, כווקטור רציף, טרנזקציה אחר טרנזקציה בכל סדר ברור אחר. כך או כך, ברור שכל חלוקה יוצרת, לכתחילה או בדיעבד, גם הקבצה של הטרנזקציות לקבוצות כגון: קבוצת טרנזקציות המופעלת ממסך תפריט מסוים; קבוצת טרנזקציות השייכת לתהליך מסוים; קבוצת טרנזקציות המטפלת בקובץ מסוים וכו'. הקבצה זו נובעת ישירות משיטת החלוקה שנבחרה. מפת"ח, כאמור, איננו מכתיב שיטה מסוימת, אלא רק מניח שיש חלוקה כלשהי לקבוצות. חלוקה נוספת בתוך כל קבוצה תהיה בשיטה המתאימה למערכת הספציפית, אך תדגיש את הסיווג לפי: טרנזקציות קלט ועדכון אוסף טרנזקציות לאחזור מידע Batch טרנזקציות טרנזקציות יוצרות/מקבלות ממשקים למערכות מידע אחרות טרנזקציות לתחזוקת/תפעול המערכת )HouseKeeping(

23 עמוד 23 מתוך יישום - מהות המערכת ההקבצה איננה ישות נוספת בעץ המערכת, אלא קשר בין רכיבים קיימים ועם כל הקושי )לכאורה(, יש בכך הקלה ופישוט. בשלב האפיון תהיה הקבצת הטרנזקציות עם רכיב מוביל מסוים, כנזכר בהנחיה לעיל. בעיצוב המערכת, תתחדד ההקבצה ותתלכד עם יותר מרכיב אחד, למשל, עם התהליכים )2.5( והמסכים )2.4(, או עם המסכים והקבצים )בגישת האובייקטים, ראה קיט בשם זה בכרך נושאים תומכים(. יש להקפיד על זיהוי ברור של הטרנזקציה הבדידה )שם וספרור(. זיהוי זה יתאים לשיטת החלוקה )ההקבצה( שנבחרה. )ראה גם הפרק סימול ישויות - קודיפיקציה בקיט תיעוד בכרך נושאים תומכים(. רצוי מאד להקפיד על קשר לאחור back( )trace של הטרנזקציות )או התהליכים( עם המטרות. היינו, לציין ליד כל טרנזקציה )או תהליך( את המטרה )מטרות( אותה)ן( היא מממשת X אינדקס כללי רשימה \ טבלה של כל הטרנזקציות במערכת. לכל טרנזקציה )שורה בטבלה( המאפיינים הבאים: שם וסימול סוג )קלט, פלט, עדכון וכו'( הקבצה )קשר לתהליכים או מסכים, או קבצים( טרנזקציה X תיאור טרנזקציות קלט ועדכון מסכי הפעולה )לפי הפורמט שצוין ב- 2.4(, קלט ופלט הדק )trigger( ההפעלה אלגוריתם הפעולה: מה עושה טרנזקציה זו. אפשר לציין זאת במלל מובנה,,Pseudo code תרשים זרימה או כל צורה ברורה אחרת קשר לרכיב 2.16 קלטים קבצים ורכיבים אחרים משתתפים: בראייה החלקית view( )partial של טרנזקציה זו, בהתייחסות ברורה לרכיבים הספציפיים: 2.9 שגרות, 2.10 טבלאות, 2.11 קבצים לוגיים וכו' קשר לאחור uses) Where used (who למטרות בקרת שלימות תיאור טרנזקציות לאחזור מידע: שאילתות ודוחות אין טעם לפרט כל דו"ח וכל טרנזקציה היוצרת אותו. יש לקבץ את כל הדוחות והשאילתות הפועלים על אוסף קבצים מוגדר, לקבוצה אחת ולתארם במרוכז. הקבצה זו תתואם עם רכיב 2.15 )דוחות המערכת( להלן. גישה זו תואמת גם את השימוש שבוודאי יעשה במחוללי שאילתות ודוחות )ראה 3.14(. תיאור טרנזקציות :batch מסך השיגור אלגוריתם הפעולה קבצים משתתפים מסך הפלט )שהוא לעתים הדו"ח(.

24 עמוד 24 מתוך יישום - מהות המערכת 2.7 היבטים תפעוליים. תיאור טרנזקציות יוצרות/מקבלות ממשקים: בדומה לטרנזקצית קלט/עדכון בתוספת קשר לרכיב 2.22 ממשקים תיאור טרנזקציות לתחזוקת/תפעול המערכת :housekeeping)( בדומה לטרנזקצית batch פירוט הסעיפים מעבר לסעיף 2.6.0, יהיה כמוצע לעיל )בהקבצות המסומנות )x, או ללא הקבצה אלא במספר רץ בלבד n.2.6, או בסימול אחר...t( ראה פרק סימול ישויות קודיפיקציה בקיט תיעוד( תחת סעיף פירוט הטרנזקציות, או בכל דרך מסודרת אחרת. מודולים )תכניות( הגדרת רכיב זה איננה בד"כ חלק מאפיון המערכת ושייכת לשלב העיצוב. ההנחיות והפירוט שלהלן ניתנים משתי סיבות עיקריות: עבור העיצוב. העיצוב ייעשה כהמשך ישיר לאפיון ותיק העיצוב הוא למעשה השלמה וכתיבה סופית של תיק זה. עבור האפיון. במקרים מיוחדים בהם כבר בשלב האפיון ידוע שהמערכת צפויה לשאול מודולים קיימים וזמינים בארגון )במערכות מידע אחרות(. במקרה זה, תיעוד המודולים יהיה פשוט ומיידי, ע"י הוצאת תדפיסים מהמערכת המשאילה או ע"י הפניה למערכת ניהול ספריות מקור מסודרת. מבנהו המדויק של רכיב זה מושפע מאד מכלי הפיתוח והתחזוקה, כולל כלים לניהול תצורה וגרסאות. המבנה המוצע להלן יותאם ע"י הפרויקט לסביבת ושיטת הפיתוח הרלוונטיות. בפתיח )במקום טקסט זה( יוסבר המבנה שאומץ. בכל מקרה, הפירוק למודולים ישמור על קשר עם טרנזקציות )רכיב 2.6( או ישירות עם תהליכים )רכיב 2.5(. תיעוד רכיב זה יכול להיעשות בגישה ריכוזית או ביזורית בגישה הריכוזית, כל המודולים של המערכת, כולל אלה שמממשים מסכים, ממשקים יתועדו כאן. בגישה הביזורית, רכיב זה יכיל את המודולים המממשים תהליכים וטרנזקציות בלבד, כהמשך ישיר של רכיבים 2.5 ו- 2.6 לעיל. מודולים המממשים מסכים וממשקים יתועדו במקומם )רכיבים 2.4 ו בהתאמה(. ההחלטה באיזו גישה לבחור היא בידי הפרויקט. לרכיב זה קשר עם רכיבים רבים אחרים, אך בעיקר עם רכיב הטרנזקציות )2.6(, שכן טרנזקציות )ותהליכים ופונקציות( ממומשים, בסופו של דבר, ע"י מודולים פיסיים. אם קיימות בארגון תבניות תיק תכנות תקניות, יש להיצמד אליהן. גם אם אין, כדאי שבפרויקט יהיה תקן כזה. תיעוד מודול הוא תיק תכנות. בפועל, יהיו תיקי התכנות בתוך המודול הפיסי, ישוכנו ישירות בספריות המודולים וייבנו ע"י כלי הפיתוח של שלב העיצוב, הבנייה והקידוד! ההסבר כאן מובא לצורך הסבר והמחשה והיא מיועד עבור מקרים בהם אכן בונים תיקי תכנות מסורתיים. ראה דיון בתיק תכנות בקיט עיצוב ובניה שבכרך מחזור חיים.

25 עמוד 25 מתוך יישום - מהות המערכת תכניות מקור SO URCE MODULES רשימה \ טבלה של כל המודולים במערכת, לכל מודול המאפיינים הבאים: שם וסימול הפנייה לתיק תכנות הפנייה לספרייה תכניות ביצוע רשימה E XECUT ABLE MODULES \ טבלה של כל המודולים במערכת, לכל מודול המאפיינים הבאים: שם וסימול הפנייה לספרייה קישור לתוכניות המקור מהלכים )פרוצדורות בקרה( רכיב זה מיועד לתיעוד מהלכי הבקרה של המערכת procedures).(control מהלכים אלה נקראים גם:,scripts פקודות מערכת ההפעלה וכו', בהתאם למערכת ההפעלה הספציפית. תיעוד הרכיב יהיה בדומה לרכיב 2.7 ע"י הפנייה לספריות המתאימות. רכיב זה מתאר באופן סטטי את ספריית המהלכים ובדומה לרכיב 2.7 לעיל הוא בא לידי ביטוי בפרט משלב עיצוב ובנייה והלאה. אופן הפעלת המהלכים הוא ברכיב 2.4 ממשק המשתמש לעיל וברכיב 4.4 תפעול המערכת להלן. שגרות )אובייקטים משותפים( היחס בין שגרה לוגית לשגרה פיסית הוא, בד"כ, 1:1 ולכן רכיב זה מכיל הן הגדרה לוגית והן הגדרה פיסית של שגרות המערכת. בשלב האפיון יש להתרכז בהגדרות הלוגיות ולהשאיר את ההגדרות הפיסיות לשלב העיצוב והבנייה. שימוש בשגרות משותפות הוא גורם חיובי וחשוב ביותר, גם מנקודת ראות צרה של המערכת הספציפית, משום: ההסתמכות על קטעי מערכת מנופים ובדוקים החסכון בכתיבה הגברת אחידות ותקינה. התשלום, לעומת זאת, הוא בצורך לוודא באופן שוטף שכל הכנסת שינויים בשגרות אלה נעשית תוך התחשבות במערכת הספציפית )שלנו(. שגרות מטפלות במגוון אלגוריתמים משותפים ומרכזיים כגון: טפול בתאריכים במבנים שונים, כולל בדיקות לוגיות והסבה ממבנה למבנה. פריטי מידע וטבלאות; נוסחאות מתמטיות; תרגום פורמטים; הודעות על שגיאות )שליחת ;)messages כתיבה, כתיבה ל-,log טיפול באמצעי קלט/פלט או קבצים מיוחדים וכו'. שגרות משותפות תתכנה במספר רמות: ברמת הפרויקט, היינו, שיתוף בין טרנזקציות ומודולים של המערכת עצמה

26 עמוד 26 מתוך יישום - מהות המערכת ברמת הארגון, היינו שימוש בספריית שגרות מרכזית המשותפת לכל מערכות המידע בארגון. הרמה הארגונית היא כמובן עדיפה. לפני שמגדירים ספרית שגרות פרטית למערכת, יש לבדוק קיומה של ספריה מרכזית בארגון ולהשתמש בה. במידה שאין כזו, אין מנוס מאפיון מלא של רכיב זה )ובנייתו בהמשך(, אך יש לוודא שלפחות ברמת המערכת הספרייה משותפת לכל הטרנזקציות והמודולים. מההיבט הטכני, שגרה היא מודול לכל דבר. מבנה שגרה )תיק תכנות( יהיה אפוא בדומה למבנה מודול. ראה 2.7 לעיל. כאמור, היחס בין שגרה לוגית לשגרה פיסית הוא, בד"כ, 1:1. זה יתרון ברור לעומת מודול רגיל המיישם טרנזקציה. התשלום הוא בכך שיש להקפיד על רישום של where used ולזכור את כל המשתמשים בשגרה. )רצוי כמובן שהרישום ייעשה בעזרת כלי ממוחשב - ניהול תצורה - ראה רכיבים 3.12 ו להלן(. כדאי מאד לזכור ששגרה משותפת תיתכן: ברמה פיסית, היינו, שימוש בקוד משותף ברמה לוגית, היינו, אלגוריתם משותף המקודד בשפות שונות. חשוב מאד להדגיש את הקשר של רכיב מרכזי זה עם רכיבים מרכזיים אחרים: טבלאות מרכזיות )רכיב 2.10 הסמוך!( טרנזקציות )2.6( ומילון השדות )2.13(. שגרות מקומיות רשימה \ טבלה של כל השגרות המקומיות\פרטיות שנכתבות כחלק מפיתוח המערכת ושייכות רק לה. לכל שגרה או שורה בטבלה המאפיינים הבאים: X שם וסימול תיאור קצר הפנייה לספרייה שגרה X תיאור מפורט של שגרה X הכולל: תרשים זרימה Flowchart קשר של Where used עם הרכיבים האחרים המשתמשים בשגרה ספריית מקור וספריית ביצוע שגרות ארגון רשימה \ טבלה של כל השגרות הארגוניות המשותפות למערכות אחרות. לכל שגרה בטבלה( המאפיינים הבאים: שורה או שם וסימול תיאור קצר הפנייה לספרייה מרכזית

27 עמוד 27 מתוך יישום - מהות המערכת שגרות צד שלישי רשימה \ טבלה של כל השגרות החיצוניות בטבלה המאפיינים הבאים: המסופקות ע"י יצרן חיצוני. לכל שגרה שורה או שם וסימול תיאור קצר הפנייה לספרייה מרכזית 2.10 טבלאות קודים שים לב להבדל בין רכיב זה ורכיב 2.11 הסמוך. ברכיב זה הכוונה לטבלאות מרכזיות, טבלאות במובן של קודים ופרמטרים אשר ניתנים בד"כ לכוונון חיצוני. טבלאות במינוח של בסיסי נתונים טבלאיים, שהם קבצי מידע לכל דבר, מקומם ברכיב 2.11 הסמוך. טבלאות קודים מקומיות )פרטיות( השייכות רק למערכת הנדונה ואשר משתנות במהלך פעילות המערכת, דינן כקובץ לכל דבר ויכללו ברכיב 2.11 להלן. היחס בין טבלה לוגית לטבלה פיסית הוא, בד"כ, 1:1 )לאחר נרמול( ולכן רכיב זה מכיל הן הגדרה לוגית והן הגדרה פיסית של טבלאות המערכת. בשלב האפיון יש להתרכז בהגדרות הלוגיות ולהשאיר את ההגדרות הפיסיות לשלב העיצוב והבנייה. שימוש בטבלאות משותפות הוא גורם חיובי וחשוב ביותר, גם מנקודת ראות צרה של המערכת הספציפית, משום: הגברת אחידות ותקינה ההסתמכות על קטעי מערכת מנופים ובדוקים החיסכון בכתיבה. התשלום, לעומת זאת, הוא הצורך לוודא באופן שוטף שכל הכנסת שינויים בטבלאות אלה נעשית תוך התחשבות במערכת הספציפית )שלנו(. הגדרה מלאה ומפורטת של טבלאות המערכת, עשויה להיות קשה ומפרכת, אך "כגודל הצער, כך השכר". להשגת מטרה חשובה זו, אין להוציא מכלל אפשרות שימוש בשמות נרדפים,,synonym או טבלאות המרה, ובלבד שמוסכם על מהות הישות. יש כמובן להימנע משמות זהים למשמעויות שונות,.homonym טבלאות משותפות תתכנה במספר רמות: ברמת הפרויקט, היינו, שיתוף בין טרנזקציות ומודולים של המערכת עצמה ברמת הארגון, היינו, שימוש בספריית טבלאות מרכזית המשותפת לכל מערכות המידע בארגון. הרמה הארגונית היא כמובן עדיפה. לפני שמגדירים ספרית טבלאות פרטית למערכת, יש לבדוק קיומה של ספריה מרכזית בארגון ולהשתמש בה. במידה שאין כזו, אין מנוס מאפיון מלא של רכיב זה )ובנייתו בהמשך(, אך יש לוודא שלפחות ברמת המערכת הספרייה משותפת לכל הטרנזקציות והמודולים. כאמור, היחס בין טבלה לוגית לטבלה פיסית הוא, בד"כ, 1:1 וזה יתרון ברור. עם זאת, יש להקפיד על רישום של where used ולזכור את כל המשתמשים בטבלה. )רצוי כמובן שהרישום ייעשה בעזרת כלי ממוחשב - ניהול תצורה - ראה רכיבים 3.12 ו להלן(. חשוב מאד להדגיש את הקשר של רכיב מרכזי זה עם רכיבים מרכזיים אחרים:

28 עמוד 28 מתוך יישום - מהות המערכת שגרות )רכיב 2.9(: במקרים רבים הגישה לטבלה היא באמצעות שגרה, שגרה וטבלה מתלכדים לעתים קרובות! קבצים )2.11(: יש לשים לב למקרים בהם טבלה היא בעצם קובץ נתונים לכל דבר. מילון פריטי מידע )2.13(: הימנע מכפילויות! מילון מונחים )2.1.4(: הימנע מכפילויות! יש לעשות שימוש מרבי בטבלאות חיצוניות ולדרוש שהיישום יהיה בכלי ממוכן. טבלאות חיצוניות )ומשותפות( המאפשרות שינוי פרמטרים חיצוני מבלי לשנות תוכניות, הם רכיב חשוב ביותר באפיון המערכת ובנייתה. ביחידות צה"ל )וכן בכל ארגון/גורם המקפיד על חיסוי המערכות וסיווגן הביטחוני או העסקי(, יש גם לפרט מי הגורמים הרשאים לגשת לטבלאות, תוך ציון לאילו צרכים, מטרות ומה הפעולה המותרת לכל גורם. ראה גם הנחיות צה"ל/מקשר"ר/מצו"ב/במ"מ. גופים הכפופים להנחיות רב"מ/במ"ת יפעלו בסעיף זה עפ"י הנחיות אלה. בכל שלושת רמות הטבלאות שלהלן: מקומי, ארגוני וחיצוני, יש להישען על הגדרות תקניות במירב האפשרי טבלאות מקומיות רשימה\אינדקס בשיטת מיון ברורה של כל הטבלאות המקומיות\פרטיות שנכתבות כחלק מפיתוח המערכת ושייכות רק לה. לכל טבלה או שורה בטבלת האינדקס המאפיינים הבאים: X שם הטבלה סמל הטבלה תיאור קצר סיווג ביטחוני/עסקי טבלה X שם הטבלה וסימולה שמות נרדפים מבנה פנימי: שם הישות, קוד, שדות נוספים)?( מרחב הערכים (Domain) ובדיקות סבירות מקור )סוג( הטבלה תקן ישראלי/בינ"ל תקן ממשלתי טבלה פרטית של המערכת, טבלאות מיוחדות לתת-מערכות מסוימות סיווג, מידור והרשאות: מי רשאי לגשת ולצורך מה. השווה עם התיאור המפורט של קבצים, ב ו להלן.

29 עמוד 29 מתוך יישום - מהות המערכת טבלאות ארגון רשימה \ אינדקס של כל הטבלאות המשותפות למערכות אחרות בארגון. כמפורט בסעיף לעיל. X טבלה X ראה X לעיל טבלאות חיצוניות רשימה \ אינדקס של כל הטבלאות החיצוניות\גלובליות באחריות ארגון אחר לעיל. כמפורט בסעיף X טבלה X 2.11 ראה X לעיל קבצים לוגיים רכיב זה מגדיר את בסיס הנתונים הלוגי - מודל הנתונים. תמונה ברורה של הקבצים הלוגיים במערכת היא חיונית וגם אפשרית, כבר בשלב האפיון )הגדרת המערכת(. ברוב מערכות המידע, אפיון מלא של רכיב זה, הוא חלק נכבד מאפיון המערכת כולה, רכיב היישום בפרט. הגדרת קבצים לוגיים כוללת: הגדרה תמציתית של כל קובץ הגדרה פרטנית של כל קובץ )ראה להלן( סכימה כוללת של עץ )או רשת( הקבצים, היינו, הקשרים בין הקבצים סכימות חלקיות )פרטיות( לתת-מערכות או לטרנזקציות, לפי הקבצות. שים לב, שרכיב זה הוא בסיס הנתונים הלוגי של המערכת, או כפי שהוא גם מכונה, מודל הנתונים, לא בסיס הנתונים הפיסי. מודל זה צריך לשקף את כל המידע הדרוש ואת כל דרכי הגישה השונים )המסלולים( הנחוצים. הגדרת הסכימות תיעשה בשיטה מקובלת )דוגמת,IA,ERD נרמול טבלאי וכו'(, רצוי תוך שימוש בכלי ממוכן. יש להדגיש את סוג הקשר: אחד לאחד )1:1(, אחד לרבים )M:1( ושדה-מפתח מקשר. חיוני ביותר שהגדרה זו תישען על מילון פריטי מידע מוסכם וברור. מכאן הקשר ההדוק עם רכיב/סעיף 2.13 להלן. קשרים עם רכיבים מרכזיים אחרים הם: טרנזקציות והמודולים )סעיפים 2.6 ו- 2.7( מילון המונחים )רכיב 2.1.4( שגרות )רכיב 2.9( במקרים רבים הגישה לקובץ היא באמצעות שגרה! הקשר העיקרי הוא כמובן עם רכיב הקבצים הפיסיים )2.12(. הנחיות לגבי קשר זה נמצאות ברכיב 2.12 להלן. יש להיזהר מכפילות עם רכיב הטבלאות )2.10( וממקרים בהם קובץ ניתן להגדרה פשוטה יותר כטבלה.

30 עמוד 30 מתוך יישום - מהות המערכת קבצים ייתכנו במספר רמות: ברמת הפרויקט, היינו, קבצים המשרתים רק מערכת ספציפית ברמת הארגון, היינו קבצי מאסטר, משותפים למספר מערכות בארגון קבצים זמניים )קבצי ביניים( קבצי ממשק. חשוב לציין הבחנות אלה, כולל אופן הגישה של המערכת לקבצים )קריאה בלבד או גם כתיבה(. בהגדרת קבצים לוגיים יש להקפיד על כללי הנרמול, אך אין להגזים. נרמול מהרמה השנייה )כל קובץ לוגי מכיל הגדרה של ישות אחת ברורה, שדה יחידני המזהה אותה וכל שאר השדות מתארים אותה(, הוא בד"כ מספק. לגבי סימול הקבצים, ראה המלצה בפרק סימול ישויות - קודיפיקציה בקיט תיעוד בכרך נושאים תומכים. ביחידות צה"ל )וכן בכל ארגון/גורם המקפיד על חיסוי המערכות וסיווגן הביטחוני או העסקי(, יש גם לפרט מי הגורמים הרשאים לגשת לקבצים )הלוגיים!(, תוך ציון לאילו צרכים, מטרות ומה הפעולה המותרת לכל גורם. ראה גם הנחיות צה"ל/מקשר"ר/מצו"ב/במ"מ. גופים הכפופים להנחיות רב"מ/במ"ת יפעלו בסעיף זה עפ"י הנחיות אלה כללי סכמות מודל הנתונים סכמה כללית: DSD,ERD או Class Diagram סכמות משנה views Partial אינדקס\טבלה של הקבצים הלוגיים, כולל המאפיינים הבאים: שם וסימול שדה מפתח תיאור כללי קובץ לוגי X שם הקובץ וסימולו שמות נרדפים תיאור תמציתי שיטת הארגון )סדרתי, גישה ישירה, רב-מפתחי( מבנה פנימי: השדות המרכיבים את הקובץ בהפניה למילון, רכיב 2.13 דגש על שדה-מפתח ראשי )יחידני( ושדות מפתח משניים. אופן גישה עיקרי )קריאה, כתיבה/קריאה( משתמשים עיקריים )קשר לאחור לרכיב 2.2( 2.11.X

31 עמוד 31 מתוך יישום - מהות המערכת קשר לאחור לטרנזקציות ותהליכים דרישות אבטחת מידע: סיווג, מידור והרשאות: מי רשאי לגשת ולצורך מה. מרחב הערכים )domain( ובדיקות סבירות היקפים )גודל, כמויות( וקצב התחלפות הנתונים )volatility( רמת פירוט, עומק הנתונים, היסטוריה רמת עדכניות קשרים ותלויות בקבצים אחרים, מידת שיתוף נתונים רמת ביזור לוגי ותפעולי דרישות גיבוי ואמינות קבצים פיסיים D A T A BASE הגדרת רכיב זה איננה בד"כ חלק מאפיון המערכת ושייכת לשלב העיצוב. ההנחיות והפירוט שלהלן ניתנים משתי סיבות עיקריות: עבור העיצוב. בד"כ העיצוב נעשה כהמשך ישיר לאפיון ותיק העיצוב הוא למעשה השלמה וכתיבה סופית של תיק האפיון. אפשר להשתמש בתיק האפיון גם לצורך העיצוב. עבור האפיון. המערכת צפויה לשאול קבצים פיסיים קיימים וזמינים בארגון. במקרה זה, תיעוד הקבצים יהיה פשוט ומיידי, ע"י הוצאת תדפיסים מהמערכת המשאילה או ע"י הפניה לבסיס נתונים קיים, בפרט אם יש לבסיס הנתונים data dictionary מסודר. הצגת הקשר בין קבצים פיסיים ללוגיים היא חיונית ביותר לבדיקת שלימות מודל הנתונים ונכונות האפיון ואיננה בהכרח דרישה לתוספת מאמץ. אדרבא, היא יכולה לחסוך עבודה רבה ברכיב זה )או בקודם( ולמנוע כפילות עם הרכיב הקודם )קבצים לוגיים(. זאת, בעיקר במקרים בהם הקשר בין קובץ לוגי לקובץ פיסי הוא 1:1. הגדרת קבצים פיסיים כוללת: הגדרה פרטנית של כל קובץ סכימה כוללת של עץ )או רשת( הקבצים, היינו, קשרים בין הקבצים סכימות חלקיות )פרטיות( בחלוקה פיסית משנית של בסיס הנתונים קשר עם הקבצים הלוגיים. שים לב שרכיב זה מכיל את ההגדרות לבסיס הנתונים הפיסי של המערכת וקשור קשר הדוק עם רכיב 3.11, להלן. הגדרת הסכימות תיעשה תוך הדגשת מודל בסיס הנתונים שבשימוש: קבצים עם אינדקס )index-sequential( קבצים בגישה ישירה,direct( hashing,random וכו'( בסיס נתונים היררכי בסיס נתונים רשתי